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REMARKS 



Applicants acknowledge with thanks the consideration given to applicants' 
remarks in their "Response To Final Office Action" dated 03/08/2004, resulting in the 
withdrawal of the prior rejection under 35 USC 103(a). 

The present paper is in response to the Office action dated 03/26/2004 in which 
each of the pending claims 1-9, 13 and 15-18 was rejected under 35 USC 102(e) as being 
anticipated by Shiigi (US 6,304,898). 

This rejection is respectfully traversed. 

An important aspect of applicants* invention is the fact that applicants allow a 
user to transmit an handwritten message in the same message field as a typewritten 
message that was previously received. A typical use of the invention is in conjunction 
with the well known email 4 *reply" function. This is depicted in FIG. 8. The user has 
already received a typewritten message from "Lillian Linnel" about a meeting with Mike 
Armstrong. The user has input a handwritten reply, saying "OK — tell him to come to FP 
this time/' Importantly, both the original typewritten message and the handwritten reply 
appear in the same message field — namely (in this example) the main body of the 
message. 

Shiigi discloses a system that, like applicants' method and apparatus, enables an 
email user to transmit email that contains a handwritten message. Applicants find 
nothing in Shiigi that explicitly mentions sending typewritten text and handwriting in the 
same message. Applicants will assume for purposes of argument, however, that in at 
least some of Shiigi's embodiments, it is indeed possible for typewritten material and 
handwritten material to be sent together in a given email transaction. Applicants note, for 
example, embodiments in Shiigi in which the handwritten material is sent as an 
attachment to an email message. See, for example, column 6, lines 53-55 of Shiigi. 

Applicants will assume for purposes of argument that a person skilled in the art 
reading Shiigi would understand that this mode of operation in Shiigi could encompass a 
scenario in which the user who had created the handwritten attachment had attached it to 
a copy of the original typewritten email that had been composed by a second user. 
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However, applicants' claims distinguish the invention from Shiigi by virtue of 
claim language that limits the invention to a method and apparatus in which the 
typewritten message and the handwritten message image are transmitted together in the 
same message field — which, as noted above, is illustratively the body of the message. See 
independent claim 1, line 9 and independent claim 15, line 8. 

Applicants* specification makes clear that an attachment to an email message, 
such as envisioned by Shiigi, is not "in the same message field" as the body of that email 
message. The specification describes two alternatives for how typewritten and 
handwritten messages could be sent together. One of these is the above-described sam e- 
message-field embodiment that the claims actually encompass. The other is an 
attachment-based embodiment that the claims do not encompass. See, for example, p. 14, 
lines 10-12 of the specification indicating that "[t]he actual handwritten image message 
may be integral to the message field or an attachment t o the email." This teaching in the 
specification makes clear that when a handwritten message in the form of an attachment, 
it is not in the same message field as the typewritten message. This, in turn, means that 
applicants* claim limitation "in the same message field" cannot be said to be met by 
Shiigi. 

Applicants do recognize that the examiner must give the words of a claim their 
broadest reasonable meaning. However, the term "message field" as applied to emails is 
sufficiently well-defined in the art as to preclude reading of the claimed term "same 
message field" as encompassing an email attachment. 

The examiner's attention is respectfully directed in this regard to the attached 
"Microsoft Knowledge Base Article 172755" that was accessed by the undersigned 
attorney on 05/25/04 and printed from the website http://support.microsoft.com . This 
article makes clear that the main portion or "body" of an email message is a field that 
does not encompass attachments. See, in particular, the following statement appearing 
under the heading "Working with the Message or Notes Field." 

The Message field is most commonly associated with a Mall 
Message form and is the main portion or "body" of the message. 

Applicants do not know when this particular article was first available to the 
public. Applicants are thus not able to represent that this article appeared on the Web 
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prior to applicants' filing date. However, since this article describes Microsoft Outlook 
97, it is believed that this article, or the previous version thereof mentioned in the article, 
was available no later than 1997, which is well prior to applicants' filing date. 

In at least one other embodiment disclosed by Shiigi, the handwritten message is 
in the form of pixel data. See, for example, col. 2, lines 45-51 and col. 8, lines 55-58. It 
does not appear that email attachments are involved in such embodiments. However, 
contrary to the requirements of applicants' claims, applicants find nothing in the 
disclosure of such embodiments in Shiigi that incorporates sending of such pixel data "in 
the same message field'* as a typewritten message that was composed by a second user. 

The Office action points specifically to col. 2, lines 18-45 of Shiigi. Those 
portions of Shiigi certainly describe the transmission of handwritten messages using 
email servers and email clients. However, applicants finding nothing within Shiigi 
generally, nor at col. 2, lines 18-45 specifically, that contradicts any of the foregoing 
discussion of what Shiigi does and does not appear to teach. Specifically, col. 2, lines 42- 
45 of Shiigi is pointed to in the Office action as anticipating the limitation "in the same 
message field." Applicants do not find anything at that point in Shiigi — or anywhere else 
in the reference — that does, in fact, anticipate that limitation, as discussed above. 

In view of the foregoing, it is submitted that applicants' independent claims I and 
15 — and thus each of applicants' dependent claims as well — distinguish the invention 
from Shiigi. Reconsideration is requested. 



Respectfully submitted, 



Paul Henry Fuoss et al. 




Reg. No. 26,585 
(732) 249-0900 



Law Office of Ronald D. Slusky 
P.O. Box 4378 

Highland Park, New Jersey 08904-4378 
Date: 5/28/2004 
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Microsoft Knowledge Base Article - 172755 

OL97: Working with the Message or Body of an Outlook Item 

View product s tha t this article applies to. 

This artide was previously published under Q17275S 
SUMMARY 

This article describes how Microsoft Outlook 97 Implements the Message or Notes field and answers some common questions regarding its use when customizing Outlook 
forms. 

MORE INFORMATION 

NOTE: This article discusses using fields and controls with Outlook forms and it Is Important to understand the difference between the two. 
For more Information on the differences between fields and controls, please see the following article In the Microsoft Knowledge Base: 
i.6897.5 How to Use ReWs and Controls with VBScrtpt 

Working with the Message or Notes Field 

The Message field fe most commonly associated with a Mall Message form and is the main portion or "body" of the message. This is a unique field because it supports Rich 
Text Formatting (RTF), meaning that you can change various attributes of the text, such as the font size and formatting. You. can also embed objects, such as shortcuts or 
Mies Into the message Meld. 

This field also exists on other Outlook forms. On a Post form, ft Is called the Message field, but on all other forms, It is referred to as the Notes field. When accessing this 
field through the Outiook object model, use the Body property of the appropriate item (Contactltem, Postltem, and so on). 

The following table summarizes the naming conventions: 



Item Type 


Field Name 


Property Name 


Mail 


Message 


Body 


Post 


Message 


Body 


Contact 


Notes 


Body 


Appointment 


Motes 


Body 


Meeting Request 


Notes 


Body 


Task 


Notes 


Body 


Task Request 


Notes 


Body 


Journal 


Notes 


Body 


Note* 


N/A 


Body 



* You cannot customize "Note" Items. 
NOTE: The remainder of this article will use the term "Message field", but unless otherwise noted, information will apply to the Notes Held as well. 
Each Outlook item contains one Message field to store RTF information; It Is not possible to add an additional field of the same type as the Message field. 

Working with the Message or Notes Control 

When designing an Outlook form, you can use the Message control more than once on a form. However, when you Insert a second Message control on a form, Outlook 
displays the following warning: 

This form has rrtore than one Message or Notes control. If more than one control is visible at run time, only one control works. 

This warning may also appear when you use the form, (at "run time") such as when you switch to a form page that contains a second Message control. 

Outlook controls are typically bound to MAPI fields to store the actual data and each Outlook form (or item) has only one field that supports RTF. Therefore, when you 
drag the Message field from the Field Chooser onto the form, It Is automatically bound to the appropriate Outlook field. You cannot change this behavior. If there is more 
than one Message field on a form, they all display the same data since there Is only one field of this type permitted for each Outlook form. However, if you change data in 
one of the Message fields, it does not automatically replicate to the other Message field unless you refresh the field by saving and reopening the form or setting the Body 
property via code. This is the main reason for the warning message mentioned above. 

The control used to display the Message field Is built into the Outlook program and is not designed for use on non-Outlook forms. However, you can add the control to the 
Control Toolbox stnoe It Is a registered control on the system. Use your right mouse button to click on a blank area of the Control Toolbox and from the context-sensitive 
menu, dick Custom Controls. "Outlook DocSite OLE Control." should appear En the list of available controls. This Is the control used to display the Message field. 

NOTE: The other Outlook-specific control is the "Outlook Recipient Collection Edit OLE Control," which is used for the To and From fields on a Mail Message. It is 
specifically designed to resolve e-mail addresses and provide other functionality specific to fields containing e-mail addresses, such as handling copy and paste between 
fields of this type. 



Working with the Body Property 

Although you can use Rich Tcxr Formatting through che user interface, when you use the Body property from Microsoft Visual Basic Script (VBScrtpt) or Microsoft Visual 
Basic for Applications automation code, all of the text formatting is lost. This is because the data type of the Body field is text, so It behaves no differently than other types 
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of controls, such as a label or text box. 

You can write VBScript code that will retrieve the Body of the message and add text to the beginning of it; however, you cannot preserve the text formatting. Use the 
Body property to retrieve the text that Is In the body! Programmatically add extra text to the beginning of the body (Uem.Body » "Added text" & Item.Body). When 
VBScript replaces the text in the field, the text Is unformatted and any previous formatting Is lost There is no workaround to this limitation. 

For more Information on manipulating text within a form's Message field, please see the following article in the Microsoft Knowledge Base: 
162995 VBScript Cannot Access Characters in the Body Property 



For more information about creating solutions with Microsoft Outlook 97, please see the following articles In the Microsoft Knowledge Base: 
16£369 How to Get Help Programming with Outlook 
1707*8 Q&A: Questions about Customizing or Programming Outlook 

The information In this article applies to: 

• Microsoft Outlook 97 

Last Reviewed; 2/26/2004(1.1) 

Keywords: kbinfo kbProgramming KB172755 

Contact lis 

it 2004 MIcrcAoft Corporation. Ail rights reserved. Terms of use Security ft Privacy Accessibility 
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